@mohdfarhanakram Thank you for taking the time to open this PR. We're genuinely glad you're contributing to CAMARA!

I think we need to briefly document the presence of .editorconfig file in the repository.

Since it is quite simple we can keep it in the root folder and update the README.md (esp. Repository Structure section).
Or we can have a new folder (like /configs ) with its own README.md to store various repository configurations - @Kevsy @hdamker WDYT?

Once PR is merged the .editorconfig file should be added to repository template and deploy it into current CAMARA repos.

Since it is quite simple we can keep it in the root folder and update the README.md (esp. Repository Structure section). Or we can have a new folder (like /configs ) with its own README.md to store various repository configurations - @Kevsy @hdamker WDYT?

@rartych I think the authoritative .editorconfig (and .gitattributes file for enforcement on git layer) should live near to the linting rule artifacts (as it has to be in line with e.g. the YAML linting). The operative copy will be in /root.

Once PR is merged the .editorconfig file should be added to repository template and deploy it into current CAMARA repos.

That's right, but we need also to think about the migration of existing repository, as we have today a mix of files with LF and CRLF line endings. I encountered that within the Release Automation as the current transformation function is normalizing to LF line endings ... with the effect that the files are looking like completely replaced in diffs which are whitespace sensitive.

I created #113 to discuss the approach we want to take to introduce .editorconfig and .gitattribute to get all CAMARA files aligned on LF line endings. Please have a view. @mohdfarhanakram @Kevsy

Thanks @rartych and @hdamker for the review!

I have prepared a README update to add .editorconfig to the Repository Structure section - happy to push that once we align on the placement.

Regarding the root vs linting/config/ question: .editorconfig must live in the project root to be recognized by editors — that's how the EditorConfig spec works. We could keep the authoritative/reference copy in linting/config/ alongside the other linting configs, but the operative copy in each API repo would still need to be in root.

Also happy to help with the broader .gitattributes and line-ending migration discussed in #113.

Yes, I agree that .editorconfig must live in the project root.

Taking into account #113 the suggestion from AI for storing shared config files that should be placed in the root of each repo (like .gitattributes, .editorconfig) is workspace-config/ folder:

workspace-config/
├── README.md              ← explains purpose, how to adopt each file
├── .gitattributes
├── .editorconfig
└── .gitignore-template    ← rename convention avoids Git picking it up locally

The workspace-config/ structure looks good to me. I will move .editorconfig there and add a README explaining the purpose and adoption steps. Happy to include .gitattributes in the same folder as part of #113 if that helps.

Moved .editorconfig into workspace-config/ as @rartych suggested. Also added .gitattributes and .gitignore-template alongside it since they were being discussed in #113 and fit naturally in the same folder.

The folder now has its own README covering adoption steps and how the configs relate to existing linting rules.

Let me know if the .gitattributes / .gitignore-template scope is fine here or if you would prefer those in a separate PR.

@rartych @hdamker - pushed the workspace-config/ update as discussed. Let me know if the scope looks right or if you'd prefer the .gitattributes in a separate PR.